package com.coderman.infosys.auth.api.facade.system;

import com.coderman.infosys.plat.auth.common.dto.PageDTO;
import com.coderman.infosys.plat.auth.common.dto.ResultDataDto;
import com.coderman.infosys.auth.api.dto.system.request.UpdateMenuRequestDTO;
import com.coderman.infosys.auth.api.dto.system.MenuDTO;
import com.coderman.infosys.auth.api.dto.system.SystemDTO;


/**
* @Description:接口
* @Author:
* @CreateTime:2022-01-02 15:27:39
* @version v1.0
*/
public interface MenuFacade{

	/**
	 *
	 * @Description 注册按钮
	 * @param menuDTO
	 * @return MenuDTO
	 */
	ResultDataDto<Boolean> registMenu(MenuDTO menuDTO);

	/**
	 *
	 * @Description 分页获取按钮信息
	 * @param pageDto
	 * @return PageDTO<SystemDTO>
	 */
	ResultDataDto<PageDTO> getMenuPageList(PageDTO pageDto);

	/**
	 *
	 * @Description 获取单条按钮信息
	 * @param menuCode
	 * @return MenuDTO
	 *
	 * 这里由于是api接口层，
	 * 所以这个接口可能一开始定义的就是为内部web系统服务的，或者
	 * 为领域内的另外一个系统提供查询的，那么此时就需要了解调用方的真正意图
	 * 有时候我们会遇到如下几种情况
	 * 1.返回menudto为了web页面做展示然后修改
	 * 2.返回menudto为了让调用方得到一些属性或者全部，
	 * 3.返回menudto因为数据权限的问题要主动去掉一些属性的值
	 * 4.返回menudto因为有内部属性值太大要优化或者menudto也要关联查很多数据
	 * 5.返回menudto是因为访问量大加了缓存，可能缓存的信息只有关键信息
	 * 此时一般的做法就是弄一个跟menudto类似的menuV2dto,menusimpledto
	 * 或者说我们增加方法名，getByMenuCodeForV2
	 * getByMenuCodeSimple
	 * 那么这两种方式其实都不够好
	 * 在DDD里面有一种规格模式来专门应对这种情况，但是规格模式目前主要用在domain层来解决复杂多场景的问题，
	 * 这里其实也一样，如果大家都有对这个menudto有不一样的要求，但是返回的还依然是以menu为主的单个对象
	 * 那就需要让查询参数稍微复杂一点，说白了大不了内部做路由，或者让调用方告诉自己你要怎么查，有什么业务规则，
	 *
	 * 这么做虽然会让查询接口变得复杂或者有点过度设计的意味，但是带来的收益也有，毕竟查询对象或者查询场景都可以通过封装的，也不都是必传
	 * 当上面的常规做法一旦形成被各种调用方调用了之后其实如果有大规模改动或者重构的话就会有大量的工作量
	 * 比如对每个接口逻辑做review,对需要的地方调整逻辑加参数，实在不行再来个新接口
	 * 当然对于测试来说也增加了测试回归的量，因为谁知道改动涉及了哪些调用方，对于开发来说这些接口改了底层是没问题，但是对于
	 * 测试来说测试只能被告知这些接口都受到了影响需要回归。
	 */
	ResultDataDto<MenuDTO> getByMenuCode(String menuCode);

	/**
	 *
	 * @Description 修改按钮信息
	 * @param dto
	 * @return Boolean
	 */
	ResultDataDto<Boolean> updateMenu(UpdateMenuRequestDTO dto);
}